Wenn Geräte uns unterbrechen, dann tun sie das oft nicht grundlos.

Eine Tastatur möchte uns beispielsweise auf einen neuen Tastendruck hinweisen, den wir

abholen und verarbeiten können.

Aber damit verändern wir auch den Zustand des Systems.

Bleiben wir beim Beispiel Tastatur.

Die Unterbrechungsbehandlung legt neue Tasten in einen Puffer, führt also ein Produce aus.

Unser Hauptprogramm entnimmt in eine Endlosschleife aus diesem Puffer, also ein Konsum.

Wenn wir unser System damit starten, wird Main ausgeführt und in der Schleife Konsum

aufgerufen.

Wenn nun eine Unterbrechung, ein Tastendruck kommt, dann wird der Ablauf unterbrochen und

die Unterbrechungsbehandlung führt das Produce aus.

Danach wird die Ausführung des Hauptprogramms fortgesetzt.

Was ist, wenn wir einfach naiv einen Puffer wie hier im Beispiel implementieren?

Nun, die Variable pos wird von beiden verwendet.

Wenn Konsum ungünstig bei –pos unterbrochen wird, kann es ein Lost Update geben.

Ein bewährtes Hausmittel gegen das Erzeuger-Verbraucher-Problem ist der gegenseitige Ausschluss.

Einfach die kritischen Abschhende im Qualtics mit einem Utick schützen und es verklemmt

sich.

Wenn Main gerade in Consum-Log aufgerufen hat und dann Produce in der Unterbrechungsbehandlung

ebenfalls Log versucht aufzurufen.

Mit viel Überlegung und atomaren Operationen wie Compare and Swap können wir ein logfreies

Consum und Produce entwickeln.

Was auch wunderbar funktioniert.

Dieser Ansatz kann sehr effizient sein, stellt jedoch keine generische Lösung dar.

Schlimmer noch, bei komplexeren Datenstrukturen kann eine derartige weiche Synchronisation

sehr schnell kompliziert und damit auch fehleranfällig werden.

Wenn wir nun jedoch ein erfolgreiches Betriebssystem schreiben wollen, müssen wir den Treiber und

Anwendungsentwicklern entgegenkommen und ihnen einfache Werkzeuge für solche Synchronisationsprobleme

in die Hand geben.

Denn sonst wird unser Betriebssystem nicht genutzt.

Ein derart einfaches Werkzeug ist die harte Synchronisation.

Dabei sperren wir mittels Klee erst die Interrupts, bevor wir Consum aufrufen.

Sollte nun eine Unterbrechung ankommen, so wird diese verzögert, bis wir die Interrupts

mit Stie wieder freigeben.

Erst danach wird die Unterbrechungsbehandlung aufgerufen und das Produce ausgeführt.

Unsere einfache, naive Implementierung vom Anfang ist also ausreichend.

Aber was wenn eine weitere Unterbrechung kommt?

Nun, diese geht dann verloren.

Wir haben mit der harten Synchronisation nun eine einfache und wartbare Variante, welche

aber hohe Latenzen verursacht und im schlimmsten Fall sogar Unterbrechungsanfragen verliert.

Ideal wäre ein Hybrid, welcher die Vorteile von weicher und harter Synchronisation vereint,

aus dem optimistischen und pessimistischen Ansatz einen realistischen macht.

Was auch die Idee hinter dem Prolog-Epilog-Modell ist.

Hierbei erledigt der Prolog das Nötigste auf der Ebene 1 mit gesperrenen Interrupts.

Der Epilog arbeitet auf einer neuen Zwischenebene, der Ebene 1 ½, bei welchem jedoch Unterbrechungen

wieder erlaubt sind.

Analog zu den Operationen für die Interrupt-Ebene 1 aus der harten Synchronisation definieren

wir Operationen für die Ebene 1 ½.

Mit CLEE wird Ebene 1 betreten und mit STIE verlassen, bei Ebene 1 ½ sind das Enter und

Leave.